作者任職凌越資訊，本文從凌越 WEBERP 的導入需求釐清角度，討論料號、客戶與價格的維護規則。以下案例與權責分工皆為示意；各項系統處理方式，應依實際使用環境及確認結果為準。

一筆訂單的品號找不到，業務先新增一個；倉庫認為是同一種商品，繼續沿用舊料號。月底統計時，才發現同一項商品的數量與銷售紀錄分散在不同代碼。

另一種情況是，業務已和客戶談妥新價格，但負責建單的人仍沿用舊條件。問題直到出貨、對帳時才被發現。

遇到這些情況，可以先檢查三件事：資料由誰定義、誰能維護，以及異動後如何確認生效。

一、先區分「提出需求」「決定內容」與「輸入系統」
主檔維護經常被簡化成「交給誰建資料」。實際上，操作系統的人，不一定能決定資料內容。

例如，新品的規格可能需要產品或工程單位確認；客戶的付款條件可能需要業務與財務共同確認。即使最後由同一位同仁輸入，內容的確認責任仍要清楚。

可以先建立一張簡單的權責表：
資料項目 應先確認的內容 內容確認者示例
料號與規格 品項識別、規格差異、單位、是否需要新料號 產品、工程或物料管理單位
客戶基本資料 交易對象、名稱、識別資料、聯絡與送貨資訊 業務及相關承辦單位
客戶交易條件 付款條件、幣別及需經核准的例外 業務、財務及授權主管
價格條件 適用客戶、料號、單位、數量條件及有效期間 業務或採購及授權主管

這張表是分工範例，企業可依組織規模調整。小型企業可能由一人兼任多個角色，但仍可以保留提出依據與確認紀錄。

IT 則協助把這些決策落實到權限、資料檢核或相關作業安排。

二、先定義什麼是「同一項資料」
以料號為例，名稱相近不一定代表可以共用代碼。判斷時，可以先確認：

• 規格、材質或版本差異，是否影響使用與追溯？
• 包裝差異應採不同料號，還是以單位換算處理？
• 不同供應商的品項，是否已確認可以替代？
• 是否需要保留客戶料號或供應商料號的對照？
  例如，同一商品以「件」與「箱」交易，若約定每箱 12 件，就要確認基本單位、交易單位與換算關係。不能只把兩筆資料的名稱改成一樣，就視為整理完成。

客戶資料也有類似問題。交易對象、帳單對象與送貨地點可能不同，應先釐清關係，再決定如何在系統中建立及對照。

新增前的查重，需要有判斷依據。 可以從既有代碼、規格與識別資料等條件比對；遇到無法確定的情況，交由資料負責人確認。

三、價格需要連同適用條件一起維護
料號與客戶屬於基本資料；價格還涉及交易對象、單位、數量及期間等條件。只留下「新價格是多少」，容易漏掉它應該適用在哪些交易。

假設企業訂定以下規則：

• 客戶 A 購買料號 P100。
• 幣別為新臺幣，計價單位為「件」。
• 以訂單日期判斷適用價格。
• 11/14 以前的新訂單單價為 100 元。
• 11/15 起的新訂單單價改為 105 元。
• 已確認的既有訂單，若需調價，另依核准程序處理。
  這時候，就可以用具體情境檢查設定與操作結果：

1. 11/14 建立、訂單日期為 11/14 的新單，應取哪個價格？
2. 訂單日期為 11/15 的新單，是否取得新價格？
3. 11/14 已確認的訂單，在 11/15 之後開啟或接續處理，價格是否符合既有訂單的約定？
   第三點尤其需要確認。主檔或價目條件改了，既有單據會受到什麼影響，應依系統的取價、重取價與單據處理方式實測。

前述日期與金額是示意測試條件。實際驗證時，建議在各情境留下訂單日期、操作日期、取價結果及處理依據，讓業務與系統顧問能核對同一個結果。

四、異動之後，要能追得回來
對重要資料的修改，建議保留以下資訊：

• 修改哪筆資料、哪個欄位？
• 原值與新值各是什麼？
• 誰提出、誰確認、誰執行？
• 何時修改、何時生效？
• 修改原因與依據是什麼？
• 是否影響既有訂單或後續作業？
  例如，客戶付款條件由月結 30 天改為月結 60 天，除了修改欄位，也要確認適用起點，以及既有交易如何處理。

若系統提供異動紀錄，應確認記錄範圍與查詢方式。若部分流程透過申請單或簽核文件管理，也要能把依據和系統中的異動對應起來。

異動追蹤也需要驗證。可以在測試環境中，挑選一筆客戶付款條件的示意資料，完成一次修改，再確認能查到哪些內容，以及哪些提出、核准或生效依據，需由申請單或簽核文件補足。

五、多套系統並用時，逐項指定資料來源
企業同時使用 ERP、CRM 或 WMS 時，可以先確認每一類資料以哪一套系統、哪個承辦單位為準。

例如，客戶聯絡資訊、交易條件與倉儲作業資料，可能有不同的維護責任。需要逐項決定：

• 哪裡可以新增或修改？
• 其他系統如何取得異動？
• 同步失敗由誰處理？
• 兩邊資料不同時，依哪個來源確認？
  這些是串接需求需要回答的問題。實際採自動同步、批次匯入或人工維護，都應有對應的確認方式。

六、把維護規則帶進凌越 WEBERP 的導入討論
以凌越 WEBERP 作為導入討論的對象時，可以先把前面的問題整理成一份確認表，逐項核對管理規則、系統處理方式與測試結果：
討論項目 企業先確認的規則 導入時的驗證方式
料號新增 哪些規格或包裝差異需要不同料號？由誰確認？ 準備有差異的示意品項，確認建立與識別方式
客戶交易條件 誰能提出與核准異動？從哪些交易開始適用？ 分別核對新單與既有單，確認處理結果符合約定
價格生效 依哪個日期與交易條件判斷？舊單如何處理？ 測試生效日前後的新單，以及已確認的既有訂單
異動追溯 哪些資料需留紀錄？提出與核准依據存在哪裡？ 選一筆測試異動，確認系統紀錄與簽核文件能否相互對應

這張表列的是需求與驗證方法。各項實作方式，應依使用版本、啟用模組、權限與設定，和導入顧問逐項確認。

企業可以先挑選最常出問題的幾個欄位，確認權責與異動流程，再用測試單據驗證。例如，一次調價，就同時檢查新訂單、既有訂單與後續出貨的處理結果，並把確認紀錄留下來。

資料由誰說了算，應該能在日常作業中找到明確答案。當內容確認、系統維護與異動生效都有依據，跨部門就更容易使用一致的資料完成工作。

你們目前最常遇到的是重複料號、客戶條件不同步，還是調價後的單據差異？